The ManArray processor uses a very long instruction word (VLIW) architecture as a means to exploit instruction-level parallelism in an application program. In a VLIW processor, multiple execution units can operate in parallel and the execution units are directly controlled by corresponding instruction fields in the VLIW. Each field can contain a short instruction word (SIW) or native instruction to be executed on a specific unit concurrently with the instructions in other fields, thus achieving high performance. One of the drawbacks associated with many prior art VLIW processor architectures is that they are not scalable. VLIW processors require wide busses connecting instruction memory and execution units. These instruction busses must have the width of the VLIW to transport VLIW contents from instruction memory to the execution units. Consequently, as a VLIW is increased in width the instruction bus and program storage increases commensurately. Bus width can be a significant problem in multiprocessor architectures.
Indirect VLIW is the solution employed for the BOPS ManArray digital signal multiprocessor family. It achieves the high performance afforded by executing multiple instructions packed in a very long instruction word (VLIW) and relaxes the requirements for the very wide instruction busses generally required. With indirect VLIW, the usual SIW size in program memory and the SIW bus width is maintained, at the expense of an additional small VLIW instruction memory (VIM) located near the execution units and the overhead to prepare the contents of VIM prior to execution. In essence, VIM acts like a programmer-controlled instruction cache. The VLIW instructions are loaded into the VIM using load VLIW instructions (LV) which consist of a delimiter instruction, the LV, followed by the instructions to be loaded into the VIM at a specific VIM address.
Another advantage of the indirect VLIW approach is the fact that code that uses non-overlapping execution units can be compressed and folded into the same VLIW memory address containing another VLIW instruction. Thus, indirect VLIW not only avoids the explicit storage of non-operational place-holders (nop instructions), but also enables code compression by storing more than one non-overlapping VLIW in the same VIM line.
When an application requires more VLIW instructions than the VIM size, one has to decide which VIM line and at which time a VLIW instruction is loaded into it. This decision is referred to as VIM allocation and requires the relocation of LV statements in application code. The need for VIM allocation and placement of LV statements arises in all back-end compiler tools that generate VLIW code, as well as hand-written assembly code. Code generators in compilers and assembly programmers in large software projects, only have a local or limited view of the whole program. Consequently, it is a difficult problem to know the requirements of the whole application program in order to efficiently allocate VLIWs in the VIM.